Problem

The task Chat panel sometimes shows "Something went wrong / Minified React error #185" (Maximum update depth exceeded) when navigating back to a task, and then stays stuck on the error fallback until the user manually clicks Try again. This is caught by the SessionView error boundary and has recurred across many users on recent packaged builds; it was reported in #2165, whose own note is the key clue — "Clicking Try again recovered the session… the error is in a render path" — i.e. the render loop is transient: it trips React's limit once and then clears on the next mount.

Why the user is stuck — two issues on main:

1. The SessionView boundary keys recovery on resetKey={taskId}, which doesn't change when you navigate back to the same task, so a transient error strands the user on the fallback until they retry by hand.
2. That boundary is wired to the bare ErrorBoundary primitive (no onError), so these crashes no longer report to error tracking — the historical boundary_name:"SessionView" events came from older builds that used the telemetry shell wrapper. We're currently blind to them.

Refs #2165

Changes

• ErrorBoundary primitive — add an opt-in, bounded autoRecover. On catch it reports via onError first (observability preserved), then schedules up to 2 self-resets — automating the manual "Try again" that Chat crashes with React error 185 (max update depth) #2165 says already works. While a recovery is pending it renders nothing instead of flashing the red error UI for a one-frame blip. A persistent loop still lands on the manual fallback (no unbounded retry storm), and the budget refills after a healthy stretch.
• SessionView boundary (TaskLogsPanel) — point it at the telemetry-reporting shell ErrorBoundary and enable autoRecover. This restores error-tracking visibility and auto-heals the transient loop so returning to a task no longer strands the user.

Behaviour is unchanged for every other boundary (autoRecover defaults off).

Note: this does not change the underlying (layout-timing) loop trigger, which needs the real app to reproduce and isolate; the restored telemetry will confirm whether it still fires so the root cause can be chased as a follow-up.

How did you test this?

Added packages/ui/src/primitives/ErrorBoundary.test.tsx (Vitest + Testing Library, real timers) which:

• replicates the defect — without autoRecover, the boundary stays on the fallback after the transient condition clears (same resetKey, no manual retry);
• verifies the fix — autoRecover clears a transient error with no manual retry and reports it first; a persistent loop is bounded and ends on the manual fallback; manual retry still works after auto-recovery is exhausted.

Ran locally (all green):

• vitest run src/primitives/ErrorBoundary.test.tsx src/shell/ErrorBoundary.test.tsx — 14 passed
• biome check on the changed files — clean
• pnpm --filter @posthog/ui typecheck — clean

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Created with PostHog Code